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Completion of Calls for the Session Initiation Protocol (SIP) 
Abstract 


The "completion of calls" feature defined in this specification 
allows the caller of a failed call to be notified when the callee 
becomes available to receive a call. 


For the realization of a basic solution without queuing, this 
document references the usage of the dialog event package (RFC 4235) 
that is described as ’Automatic Redial’ in "Session Initiation 
Protocol Service Examples" (RFC 5359). 


For the realization of a more comprehensive solution with queuing, 
this document introduces an architecture for implementing these 
features in the Session Initiation Protocol where "completion of 
calls" implementations associated with the caller’s and callee’s 
endpoints cooperate to place the caller’s request for completion of 
calls into a queue at the callee’s endpoint; when a caller’s request 
is ready to be serviced, re-attempt of the original, failed call is 
then made. 


The architecture is designed to interoperate well with existing 
completion of calls solutions in other networks. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6910. 
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Introduction 


The Completion of Calls (CC) feature allows the caller of a failed 
call to have the call completed without having to make a new call 
attempt while guessing when the callee becomes available. When the 
caller requests the use of the CC feature, the callee will be 
monitored for its availability. When the callee becomes available, 


the callee will be given a certain time frame for initiating a call. 


If the callee does not initiate a new call within this time frame, 
then the caller will be recalled. When the caller accepts the CC 
recall, then a CC call to the callee will automatically start. If 
several callers have requested the CC feature on the same callee, 
they will be recalled in a predefined order, which is usually the 
order in which they have requested the CC feature. 


This document defines the following CC features: 


Completion of Calls to Busy Subscriber (CCBS): The callee is busy. 
The caller is recalled after the callee is no longer busy. 


Completion of Calls on No Reply (CCNR): The callee does not answer 
the call. The caller is recalled after the callee has completed 
new call. 
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Lis 


Completion of Calls on Not Logged-in (CCNL): The callee is not 
registered. The caller is recalled after the callee has 
registered again. 


Requirements Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document uses terms from [RFC3261]. 
Terminology 


For the purpose of this service, we provide the following 
terminology: 


Callee: a destination of the original call, and a target of the CC 
Call. 


Caller: the initiator of the original call and the CC request. The 
user on whose behalf the CC call is made. 


Callee’s monitor: a logical component that implements the CC queue 
for destination user(s)/UA(s) (User Agent(s)) and performs the 
associated tasks, including sending CC recall events, analogous to 
the destination local exchange’s role in Signaling System 7 
(SS7) CC. 


Caller’s agent: a logical component that makes CC requests and 
responds to CC recall events on behalf of originating 
user(s) /UA(s), analogous to the originating local exchange’s role 
in SST CG, 


CC, or Completion of Calls: a service that allows a caller who 
failed to reach a desired callee to be notified when the callee 
becomes available to receive a call. 


CC activation: the indication by the caller to the caller’s agent 
that the caller desires CC for a failed original call; this 
implies an indication transmitted from the caller's agent to the 
callee’s monitor of the desire for CC processing. 


CCBS, or Completion of Calls to Busy Subscriber: a CC service 
provided when the initial failure was that the destination UA was 
busy. 
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CCNR, or Completion of Calls on No Reply: a CC service provided when 


the initial failure was that the destination UA did not answer. 


CCNL, or Completion of Calls on Not Logged-in: a CC service provided 


cc 


cc 


cc 


cc 


cc 


cc 


cc 


cc 


cc 


when the initial failure was that the destination UA was not 
registered. 


call: a call from the caller to the callee, triggered by the CC 
service when it has determined that the callee is available. 


indicator: an indication in the CC call INVITE used to prioritize 
the call at the destination. 


possible indication: the data in responses to the INVITE of the 
original call that indicate that CC is available for the call. 


recall: the action of the callee’s monitor selecting a particular 
CC request for initiation of a CC call, resulting in an indication 
from the caller’s agent to the caller that it is now possible to 
initiate a CC call. 


recall events: event notifications of event package 
"call-completion", sent by the callee’s monitor to the caller’s 
agent to inform it of the status of its CC request. 


recall timer: maximum time the callee’s monitor will wait for the 
caller’s response to a CC recall. 


request: the entry in the callee’s monitor queue representing the 
caller’s request for CC processing, that is, the caller’s CC 
subscription. 


service duration timer: maximum time a CC request may remain 
active within the network. 


queue: a buffer at the callee’s monitor that stores incoming 
calls that are targets for CC. Note: This buffer may or may not 
be organized as a queue. The use of the term "queue" is analogous 


to SS7 usage. 


CCE, or CC Entity: the representation of a CC request, or, 


equivalently, an existing CC subscription within the queue of a 
callee’s monitor. 


Worley, et al. Standards Track [Page 5] 


RFC 6910 Completion of Calls April 2013 


Failed call: a call that does not reach a desired callee, from the 
caller’s point of view. Note that a failed call may be successful 
from the SIP point of view; e.g., if the call reached the callee’s 
voicemail but the caller desired to speak to the callee in real 
time, the INVITE receives a 200 response, but the caller considers 
the call to have failed. 


Notifier: the UA that generates NOTIFY requests for the purpose of 
notifying subscribers of the callee’s availability; for the CC 
service, this is the task of the callee’s monitor. 


Original call: the initial call that failed to reach a desired 
destination. 


Retain option: a characteristic of the CC service; if supported, CC 
calls that again encounter a busy callee will not be queued again, 
but the position of the caller’s entry in the queue is retained. 
Note that SIP CC always operates with the retain option active; a 
failed CC call does not cause the CC request to lose its position 
in the queue. 


Signaling System 7, or SS7: the signaling protocol of the public 
switched telephone network, defined by ITU-T Recommendations 0.700 
through 0.849. 


Subscriber: the UA that receives NOTIFY requests with information of 
the callee’s availability; for the CC service, this is the task of 
the caller’s agent. 


Suspended CC request: a CC request that is temporarily not to be 
selected for CC recall. 


4. Solution 
4.1. CC Architecture 


The CC architecture augments each caller’s UA (or User Agent Client 
(UAC)) wishing to use the CC features with a "CC agent" (also written 
as "caller’s agent"). 


It augments each callee’s UA (or User Agent Server (UAS)) wishing to 
be the target of the CC features with a "CC monitor" (also written as 
"callee’s monitor"). 


The caller’s agent and callee’s monitor functions can be integrated 
into the respective UAs, be independent end-systems, or be provided 
by centralized application servers. The two functions, though 
associated with the two UAs (caller and callee), also may be provided 
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as services by the endpoints’ home proxies or by other network 
elements. Though it is expected that a UA that implements CC will 
have both functions so that it can participate in CC as both caller 
and callee, the two functions are independent of each other. 


A caller’s agent may service more than one UA as a collective group 
if a caller or population of users will be shared between the UAs, 
and especially if the UAs share an address of record (AOR). 


The caller’s agent monitors calls made from the caller’s UA(s) in 
order to determine their destinations and (potentially) their final 
response statuses, and the Call-Info header fields of provisional and 
final responses to invoke the CC feature. 


A callee’s monitor may service more than one UA as a collective group 
if a callee or population of users will be shared between the UAs, 
and especially if the UAs share an AOR. The callee’s monitor may 
supply the callee’s UAS(s) with Call-Info header field values for 
provisional and final responses. 


The callee’s monitor also instantiates a presence server used to 
monitor the caller’s availability for CC recall. 


The callees using the UA(s) may be able to indicate to the callee’s 
monitor when they wish to receive CC calls. 


In order to allow flexibility and innovation, most of the interaction 
between the caller’s agent, the caller(s) (user(s)), and the caller’s 
UA(s) is out of the scope of this document. Similarly, most of the 
interaction between the callee’s monitor, the callee(s), and the 
callee’s UA(s) is out of the scope of this document, as is the policy 
by which the callee’s monitor arbitrates between multiple CC 
requests. 


The caller’s agent must be capable of performing a number of 
functions relative to the UA(s). The method by which it does so is 
outside the scope of this document, but an example method is 
described in Appendix A. The callee’s monitor must be capable of 
performing a number of functions relative to the UA(s). The method 
by which it does so is outside the scope of this document, but an 
example method is described in Appendix B. 


As a proof of concept, simple caller’s agents and callee’s monitors 
can be devised that interact with users and UAs entirely through 
standard SIP mechanisms [RFC6665] [RFC4235] [RFC3515], as described 
in the Appendices. 
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The callers using the UA(s) can indicate to the caller’s agent when 
they wish to avail themselves of CC for a recently made call that the 
callers determined to be unsuccessful. The caller’s agent monitors 
the status of the caller’s UA(s) to determine when they are available 
to be used for a CC recall. The caller’s agent can communicate to 
the caller’s UA(s) that a CC recall is in progress and inquire if the 
relevant caller is available for the CC recall. 


The callee’s monitor may utilize several methods to monitor the 
status of the callee’s UA(s) and/or their users for availability to 
receive a CC call. This can be achieved through monitoring calls 
made to the callee’s UA(s) to determine the callee’s status, the 
identity of callers, and the final responses for incoming calls. And 
in a system with rich presence information, the presence information 
may directly provide this status. In a more restricted system, this 
determination can depend on the mode of the CC call in question, 
which is provided by the URI ’m’ parameter. For example, a UA is 
considered available for CCBS ("m=BS") when it is not busy, but a UA 
is considered available for CCNR ("m=NR") when it becomes not busy 
after being busy with an established call. 


The callee’s monitor maintains information about the set of INVITEs 
received by the callee’s UA(s) considered unsuccessful by the caller. 
In practice, the callee’s monitor may remove knowledge about an 
incoming dialog from its set if local policy at the callee’s monitor 
establishes that the dialog is no longer eligible for CC activations. 


4.2. CC Procedures 
The caller’s UA sends an INVITE to a request-URI. One or more forks 
of this request reach one or more of the callee’s UAs. If the CC 


feature is available, the callee’s monitor (note there can be a 
monitor for each of the callee’s UAs) inserts a Call-Info header 
field with its URI and with "purpose=call-completion" in appropriate 
non-100 provisional or final responses to the initial INVITE and 
forwards them to the caller. The provisional response SHOULD be sent 
reliably if the INVITE contained a Supported header field with the 
option tag 100rel. On receipt of a non-100 provisional or a final 
response with the indication that the CC feature is available, the 
calling user can invoke the CC feature. 


The caller indicates to the caller’s agent that he wishes to invoke 
CC services on the recent call. Note that from the SIP point of 
view, the INVITE may have been successful, but from the user’s point 
of view, the call may have been unsuccessful. For example, the call 
may have connected to the callee’s voicemail, which would return a 
200 status to the INVITE but from the caller’s point of view is "no 
reply". 
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In order to receive information necessary for the caller to complete 
the call at the callee, the caller’s agent subscribes to the 
call-completion event package at the callee’s monitor. 


The possibility of the caller completing the call at the callee is 
also known as the CC state (cc-state) of the caller. The cc-states 
comprehend the values "queued" and "ready" (for CC). 


In order to receive information from all destinations where the 
callee will be reachable, the caller’s agent sends a SUBSCRIBE 
request for the call-completion event package to the original 
destination URI of the call and to all known URIs of the callees’ 
monitors (which are provided by Call-Info header fields in 
provisional and final responses to the INVITE). Each callee’s 
monitor uses the subscription as an indication that the caller is 
interested in using the CC feature with regard to the particular 
callee. 


Each callee’s monitor keeps a list or queue of subscriptions from 
callers’ agents, representing the requests from the callers’ agents 


to the callee’s monitor for CC services. These subscriptions are 
created, refreshed, and terminated according to the procedures of 
[RFC6665]. 


Upon receiving a SUBSCRIBE request from the caller’s agent, the 
callee’s monitor instantiates a presence state for the caller’s UA 
that can be modified by the caller’s UA to indicate its availability 
for the CC call. Upon instantiation, the caller’s presence status at 
the callee’s monitor is "open". 


When the callee’s monitor determines that the callee and/or callee’s 
UA is available for a CC call, it selects a caller to execute the CC 
call and sends a CC event update ("cc-state: ready") via a NOTIFY 
request to the selected subscription of the caller’s agent, telling 
it to begin the CC call to the callee’s UA. 


When the caller’s agent receives this update, it initiates a CC 
recall by calling the caller’s UA and then starts the CC call to the 
callee’s UA, using third-party call control procedures in accordance 
with [RFC3725]. The caller’s agent can also check by other means 
whether the caller is available to initiate the CC call to the 
callee’s UA. If the caller is available, the caller’s agent directs 
the caller’s UA to initiate the CC call to the callee’s UA. 


The caller’s agent marks the CC call as such by adding a specific SIP 


URI parameter to the Request-URI, so it can be given precedence by 
the callee’s monitor in reaching the callee’s UA. 
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If the caller is not available on receipt of the "ready for recall" 
notification, the caller’s agent suspends the CC request at the 
callee’s monitor by sending a PUBLISH request containing presence 
information to the presence server of the callee’s monitor, informing 
the server that the presence status is "closed". Once the caller 
becomes available for a CC call again, the caller’s agent resumes the 
CC request by sending another PUBLISH request to the callee’s 
monitor, informing the monitor that the presence status is "open". 


On receipt of the suspension request, the callee’s monitor performs 
the monitoring for the next non-suspended CC request in the queue. 

On receipt of the resume from the previously suspended caller’s agent 
that was at the top of the queue, the callee’s monitor performs the 
callee monitoring for this caller’s agent. 


When the CC call fails, there are two possible options: the CC 
feature has to be activated again by the caller’s agent subscribing 
to the callee’s monitor, or CC remains activated and the original CC 
request retains its position in the queue if the retain option is 
supported. 


The retain option (see Section 3) determines the behavior of the 
callee’s monitor when a CC call fails. If the retain option is 
supported, CC remains activated, and the original CC request 

retains its position in the queue. Otherwise, the CC feature is 
deactivated, and the caller’s agent would have to subscribe again to 
reactivate it. 


A monitor that supports the retain option provides the 
cc-service-retention header in its CC events. A caller’s agent that 
also supports the retain option uses the presence of this header to 
know not to generate a new CC request after a failed CC call. 


Monitors not supporting the retain option do not provide the 
cc-service-retention header. A failed CC call causes the CC request 
to be deleted from the queue, and these monitors will terminate the 
corresponding subscription of the caller’s agent to inform that agent 
that its CC request is no longer in the queue. A caller’s agent that 
does not support the retain option can also terminate its 
subscription when a CC call fails, so it is possible that both the 
caller’s agent and the callee’s monitor may be signaling the 
termination of the subscription concurrently. This is a normal SIP 
events [RFC6665] scenario. After the subscription is terminated, the 
caller’s agent may create a new subscription (as described in 

Section 6.2) to reactivate the CC feature for the original call. 
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4.3. Automatic Redial as a Fallback 


Automatic Redial is a simple end-to-end design. An Automatic Redial 
scenario is described in [RFC5359], Section 2.17. This solution is 
based on the usage of the dialog event package. If the callee is 
busy when the call arrives, then the caller subscribes to the 
callee’s call state. The callee’s UA sends a notification when the 
callee’s call state changes. This means the caller is also notified 
when the callee’s call state changes to ’/terminated’. The caller is 
alerted, then the caller’s UA starts a call establishment to the 
callee again. If several callers have subscribed to a busy callee’s 
call state, they will be notified at the same time that the call 
state has changed to ’terminated’. The problem with this solution is 
that it might happen that several recalls are started at the same 
time. This means it is a heuristic approach with no guarantee of 
success. 


There is no interaction between CC and Automatic Redial, as there is 
a difference in the behavior of the callee’s monitor and the caller 
when using the dialog event package for receiving dialog information 
or for aggregating a CC state. 


4.4. Differences from SS7 
SIP CC differs in some ways from the CCBS and CCNR features of SS7 


(which is used in the Public Switched Telephone Network (PSTN)). For 
ease of understanding, we enumerate some of the differences here. 


As there is no equivalent to the forking mechanism in SS7, in the 
PSTN, calls can be clearly differentiated as successful or 


unsuccessful. Due to the complex forking situations that are 
possible in SIP, a call may fail from the point of view of the user 
and yet have a success response from SIP’s point of view. (This can 


happen even in simple situations: e.g., a call to a busy user that 
fails over to his voicemail receives a SIP success response, even 
though the caller may consider it "busy subscriber".) Thus, the 
caller must be able to invoke CC even when the original call appeared 
to succeed. To support this, the caller’s agent must record 
successful calls as well as unsuccessful calls. 


In SIP, only the caller’s UA or service system on the originating 
side and the callee’s UA or service system on the terminating side 
need to support CC for CC to work successfully between the UAs. 
Intermediate SIP systems (proxies or back-to-back user agents 
(B2BUAs)) do not need to implement CC; they only need to be 
transparent to the usual range of SIP messages. In the PSTN, 
additionally, intermediate nodes like media gateway controllers have 
to implement the CC service. 
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5. 


CC Queue Model 


The callee’s monitor manages CC for a single URI. This URI is likely 
to be a published AOR, or more likely "non-voicemail AOR", but it may 
be as narrowly scoped as a single UA’s contact URI. The callee’s 


monitor manages a dynamic set of CC entities (called "CCEs"), which 
represent CC requests, or equivalently, the existing incoming CC 
subscriptions. This set is also called a queue, because a queue data 
structure often aids in implementing the policies of the callee’s 
monitor for selecting CCEs for CC recall. 


Each CCE has an availability state, determined through the caller’s 
presence status at the callee’s monitor. A presence status of "open" 
represents a CCE’s availability state of "available", and a presence 
status of "closed" represents a CCE’s availability state of 
"unavailable". 


Each CCE has a recall state that is visible via subscriptions. The 
recall state is either "queued" or "ready". 


Each CCE carries the From URI of the SUBSCRIBE request that caused 
its creation. 


CC subscriptions arrive at the callee’s monitor by addressing the 
URIs the callee’s monitor returns in Call-Info header fields. The 
request-URI of the SUBSCRIBE request determines the queue to which 
the resulting CCE is added. The resulting subscription reports the 
status of the queue. The base event data is the status of all the 
CCEs in the queue, but the data returned by each subscription is 
filtered to report only the status of that subscription’s CCE. 
(Further standardization may define means for obtaining more 
comprehensive information about a queue.) 


When a CCE is created, it is given the availability state "available" 
and recall state "queued". 


When the callee’s monitor receives Presence Information Data Format 
(PIDF) bodies [RFC3863] via PUBLISH requests [RFC3903], these PUBLISH 
requests are expected to be sent by subscribers to indirectly suspend 
and resume their CC requests by modifying its CCE availability state. 
A CCE is identified by the request-URI (if it was taken from a CC 
event notification that identifies the CCE) or the From URI of the 
request (matching the From URI recorded in the CCE). Receipt of a 
PUBLISH with status "open" sets the availability state of the CCE to 
"available" (resume); status "closed" sets the availability state of 
the CCE to "unavailable" (suspend). 
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A CC request is eligible for recall only when its CCE’s availability 
state is "available" and the "m" value of the CCE also indicates an 
available state. The callee’s monitor MUST NOT select for recall any 
CC requests that fail to meet those criteria. Within that 
constraint, the selections made by the callee’s monitor are 
determined by its local policy. Often, a callee’s monitor will 
choose the acceptable CCE that has been in the queue the longest. 
When the callee’s monitor has selected a CCE for recall, it changes 
the CCE’s recall state from "queued" to "ready", which triggers a 
notification on the CCE’s subscription. 


If a selected subscriber then suspends its request by sending a 
PUBLISH with the presence status "closed", the CCE becomes 
"unavailable", and the callee’s monitor changes the CCE’s recall 
state to "queued". This may cause another CCE (e.g., a CCE that has 
been in the queue for less time) to be selected for recall. 


The caller’s presence status at the callee’s monitor is terminated 
when the caller completes its CC call or when the subscription of the 
caller’s agent at the callee’s monitor is terminated. 


6. Caller’s Agent Behavior 
6.1. Receiving the CC Possible Indication 


The caller’s agent MUST record the From URI and SHOULD record the 
final request status that the caller’s UA received along with the 
contents of Call-Info header fields of provisional and final 
responses. 


Note that receiving a CC possible indication also depends on the 
aggregation of final responses by proxies; in the case of 4xx 
responses, some 4xx responses are more likely to be sent to the 
caller. 


6.2. Subscribing to CC 


For CC activation, the caller’s agent MUST send a SUBSCRIBE to all 
known callee’s monitor URIs. A callee’s monitor URI may be provided 
in the Call-Info header field in provisional and final responses to 
the INVITE sent back by the callee’s monitor(s). Additionally, the 
caller’s agent SHOULD include the original request-URI that it sent 
the original INVITE to, in its set of callee’s monitor URIs, when it 
is unclear if the call has forked to additional callees whose 
responses the caller has not seen. A SUBSCRIBE to the original 
request-URI alone is used in cases where the caller’s agent has not 
received or does not remember any callee’s monitor URI. The caller’s 
agent SHOULD add an 'm” parameter to these URIs in order to indicate 
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to the callee’s monitor the desired CC mode. The ’m’ parameter 
SHOULD have the value of the ’m’ parameter received in the Call-Info 
header field of the responses to the original INVITE. 


Gl 


To minimize redundant subscriptions, these SUBSCRIBES SHOULD be 
presented as forks of the same transaction, as defined by 

Section 8.2.2.2 of [RFC3261], if the caller’s agent is capable of 
doing so. 


The agent MUST NOT maintain more than one CC request for a single 
caller and directed to a single original destination URI. Ifa 
caller requests CC a second time for the same destination URI, the 
agent MUST consolidate the new request with the existing CC request 
by either reusing the existing CC subscriptions or terminating and 
then recreating them. For this purpose, equality of callers is 
determined by comparing callers’ AORs and equality of destination 
URIs is determined by comparing them per [RFC3261] Section 19.1.4. 


When generating these SUBSCRIBEs, the From URI MUST be the caller’s 
AOR. The To URI SHOULD be the destination URI of the original call 
(if the agent knows that and can insert it into the To header) and 
otherwise MUST be the request-URI of the SUBSCRIBE. 


The SUBSCRIBE SHOULD have header fields to optimize its routing. In 
particular, it SHOULD contain "Request-Disposition: parallel" and an 
Accept-Contact header field to eliminate callee UAs that are not 
acceptable to the caller. 


The caller’s agent MUST be prepared to receive multiple responses for 
multiple forks of the SUBSCRIBE and to have multiple subscriptions 
established. The caller’s agent must also be prepared to have the 
SUBSCRIBE fail; in which case, CC cannot be invoked for this original 
call. 


If the caller’s agent no longer wants to initiate the CC call (e.g., 
because the caller has deactivated CC), the caller’s agent terminates 
the subscription in accordance with [RFC6665] or suspends the 
subscription(s) as specified in Section 6.5. 


6.3. Receiving a CC Recall Notification 


When receiving a NOTIFY with the cc-state set to "ready", the 
caller’s agent SHOULD suspend all other subscriptions to CC, by 
following the step in Section 6.5, in order to prevent any other CC 
requests from this caller from receiving CC recalls. The caller’s 
agent starts the CC recall to the caller by confirming that the 
caller would be able to initiate a CC call, e.g., by calling the 
caller’s UA(s). 
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6.4. Initiating a CC Call 


If the caller is available for the CC call and willing to initiate 
the CC call, the caller’s agent causes the caller’s UA to generate a 
new INVITE towards the callee. The caller’s UA MAY add an ’m’ URI 
parameter with the value of the ’m’ parameter received in the 
Call-Info header in the response to the original INVITE, in order to 
specify his preferences in CC processing and to prioritize the CC 
call. The INVITE SHOULD be addressed to the URI specified in the 
cc-URI of the NOTIFY, or, if that’s not available, it SHOULD use the 
URI in the Call-Info header field of the response to the original 
INVITE; if that’s not available, it MAY use the request-URI of the 
original INVITE, if this URI was recorded. Note that the latter 
choice may not provide ideal routing, but, in simple cases, it is 
likely to reach the desired callee or callee’s monitor. 


6.5. Suspending CC 


If the caller is not available for the CC recall, the CC request 
SHALL be suspended by the caller’s agent until the caller becomes 
available again or if the conditions relevant to the local suspension 
policy of the caller’s agent have changed. To suspend the CC 
request, the caller’s agent SHALL publish the caller’s presence state 
by sending a PUBLISH request to each callee’s monitor where the 
presence server for CC resides in accordance with the procedures 
described in [RFC3903], giving the PIDF state "closed" for the 
caller’s identity as presentity. The PUBLISH request SHOULD contain 
an Expires header field with a value that corresponds to the current 
value of the remaining CC subscription duration. 


Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, 
or within the corresponding SUBSCRIBE dialog, or if that is not 
possible, to the corresponding callee’s monitor URI received in the 
Call-Info header field of the NOTIFY, or if one is not available, the 
Contact address of the subscription. 


6.6. Resuming CC 


When the caller is no longer busy, or if the conditions relevant to 
the suspension policy of the caller’s agent have changed, then the CC 
request SHALL be resumed by the caller’s agent. To resume a CC 
request, the caller’s agent SHALL publish the caller’s presence state 
by sending a PUBLISH request to each callee’s monitor in accordance 
with the procedures described in [RFC3903], informing each monitor 
that the PIDF state is "open"; this request will otherwise be 
constructed in the same way as the suspend PUBLISH request. 
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7. 


7. 


In the case where the caller’s agent has sent several CC suspension 
requests to different callee’s monitors and the caller becomes 
available again, as determined by the local resumption policy of the 
caller’s agent, the caller’s agent MAY send a PUBLISH to resume a CC 
request to each callee’s monitor for which there is a suspended CC 
request. Note that the resumption policy of the caller’s agent may 
prescribe a manual resumption; thus, a suspended CC request should 
not be automatically resumed. 


Callee’s Monitor Behavior 
1. Sending the CC Possible Indication 


The callee’s monitor MUST record the From URI and MAY record the 
final request status(es) returned by the callee’s UA(s). 


If the callee’s monitor wants to enable the caller to make use of the 
CC service, it MUST insert a Call-Info header field with 
"purpose=call-completion" in the final response message (e.g., ina 
486 to enable CC due to busy subscriber) and at least one non-100 
provisional response message (e.g., in a 180 due to no response) to 
the initial INVITE when forwarding it to the caller. The non-100 
provisional response message SHOULD be sent reliably if the INVITE 
contained a Supported header field with the option tag 100rel. The 
Call-Info header field values defined in this specification 
positively indicate that CC is available for the failed fork of the 
call. 


The callee’s monitor SHOULD insert a URI in the Call-Info header 
field where the caller’s agent should subscribe for CC. Ideally, it 
is a globally routable URI [RFC5627] for the callee’s monitor. In 
practice, it may be the callee’s AOR, and the SUBSCRIBE will be 
routed to the callee’s monitor only because it specifies "Event: 
call-completion". 


In order to enable CC, the Call-Info header field MUST be set up 
according to the following scheme: 


Call-Info: monitor-URI;purpose=call-completion;m=XX 


The ’m’ parameter defines the "mode" of CC. The "m=NR" parameter 
indicates that it failed due to lack of response, the "m=BS" 
parameter indicates that it failed due to busy subscriber, and the 
"m=NL" parameter indicates that it failed due to non-registered 
subscriber (no devices are registered for the AOR contacted). The 
’m’ parameter is useful for PSTN interworking and assessing presence 
information in the callee’s monitor. It is possible that other 
values will be defined in future. It is also permissible to omit the 
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’m’ parameter entirely. Implementations MUST accept CC operations in 
which the 'm” parameter is missing or has an unknown value, and 
execute them as best they can in their environment (which is likely 
to be a degraded service, especially when interoperating with SS7). 


7.2. Receiving a CC Subscription 


The callee’s monitor MUST be prepared to receive SUBSCRIBEs for the 
call-completion event package directed to the URIs of UA(s) that it 
is servicing and any URIs that the callee’s monitor provides in 
Call-Info header fields. The SUBSCRIBES MUST be processed in 
accordance with the procedures defined in [RFC6665], establishing 
subscriptions. These subscriptions represent the request from the 
caller’s agent for CC services. 


If the monitor receives two or more SUBSCRIBEs that have the same 
Call-Id header field value and the monitor considers the request-URIs 
of the received SUBSCRIBES to request the status of the same set of 
UAs, then they are redundant forks of one SUBSCRIBE request, and the 
monitor SHOULD reject all but one of the requests with 482 (Merged 
Request) responses. 


The monitor MAY determine that an incoming CC SUBSCRIBE is a 
duplicate of an existing CC subscription if (1) the Call-Id header 
field values are different, (2) the From URIs (i.e., the caller’s 
AORs) are the same (per [RFC3261] Section 19.1.4), (3) the To URIs 
(which should be the request-URI of the original call) have the same 
user and hostport components, and (4) the monitor considers the 
request-URIs of the received SUBSCRIBEs to request the status of the 
same set of UAs. 


If the monitor determines that a new subscription is a duplicate of 
an existing subscription, it MAY terminate the existing subscription 
in accordance with the procedures defined in [RFC6665]. In any case, 
it MUST establish the new subscription. 


The callee’s monitor may apply restrictions as to which caller’s 
agents may subscribe. 


The continuation of the subscription of the caller’s agent indicates 
to the callee’s monitor that the caller’s agent is prepared to 
initiate the CC call if it is selected for the "ready" state. If the 
callee’s monitor becomes aware of a subscription that cannot be 
selected for a CC recall, it SHOULD terminate the subscription in 
accordance with [RFC6665]. 
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7.3. Sending a CC Notification 


The call-completion event package returns various points of 
information to the caller’s agent, but the vital datum it contains is 
the cc-state of the CC request of the caller’s agent as stored in the 


CC queue; in the beginning, this cc-state is "queued". When the 
cc-state of the agent’s request changes, the callee’s monitor MUST 
send a NOTIFY for a CC event to the caller’s agent. The notification 


SHOULD also contain a URI that can be used for suspension requests. 
Ideally, it is a globally routable URI [RFC5627] for the callee’s 
monitor. In practice, it may be the callee’s AOR, and the SUBSCRIBE 
will be routed to the callee’s monitor only because it specifies 
"Event: call-completion". 


The call-completion event package provides limited information about 
the policy of the callee’s monitor. In particular, as in the PSTN, 
the "cc-service-retention" datum gives an indication of the "service 
retention" attribute, which indicates whether the CC request can be 
continued to a later time if the CC call fails due to the callee’s 
UA(s) being busy. If the callee’s monitor supports the 
service-retention option, the callee’s monitor SHOULD include the 
cc-service-retention parameter. 


The callee’s monitor has a policy regarding when and how it selects 
CC requests for the recall. This policy may take into account the 
type of the requests (e.g., CCNR vs. CCBS), the state of the callee’s 
UA(s), the order in which the CC requests arrived, the length of time 
the CC requests have been active, and any previous attempts of CC 
activations for the same original call. The callee’s monitor will 
usually choose only one CC request for the recall at a time, but if 
the callee’s UA(s) can support multiple calls, it may choose more 
than one. The callee’s monitor will usually choose the oldest active 
request. 


when the callee’s monitor changes the state datum for the chosen 
subscription from "queued" to "ready", the callee’s monitor MUST send 
a NOTIFY for the subscription of the caller’s agent with the cc-state 
set to "ready" (recall notification). The NOTIFY SHOULD also contain 
in the cc-URI a URI to be used in the CC call. In practice, this may 
be the AOR of the callee. 


Upon sending the recall notification, the callee’s monitor MUST start 
a recall timer. It is RECOMMENDED to use a value between 10 and 

20 seconds, which corresponds to the recommendation for the CC 
services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733] 
documents. 
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7.4. Receiving a CC Call 


The callee’s UA(s) and the callee’s monitor may give the CC call 
precedence over non-CC calls by evaluating the presence of the ’m’ 
URI parameter and the From header of the INVITE request. The 
callee’s monitor supervises the receiving of the CC call. Upon 
arrival of the CC call, the recall timer MUST be stopped. If the CC 
call does not arrive at the callee’s UA(s) before the expiry of the 
recall timer, the callee’s monitor SHOULD stop processing the recall 
and change the value of the cc-state datum to "queued" if it supports 
the retain option, and terminate the subscription if it doesn’t 
support the retain option. Similarly, if the CC call is not 
accepted, the callee’s monitor will stop the CC recall processing. 
Depending on its policy, the same original call may be selected again 
for a CC recall at a later time. If the CC call succeeds, the 
callee’s monitor MUST terminate the relevant subscription in 
accordance with [RFC6665] and MUST remove any associated presence 
event state used for suspend and resume for the caller of the CC 
call. 


Once the CC call has been terminated, successfully or unsuccessfully, 
the policy of the callee’s monitor MAY specify that another CC 
request for a recall be selected. Note also that according to the 
policy of the callee’s monitor several recalls may be processed at 
the same time. 


7.5. Receiving a CC Suspension 


The monitor may receive PUBLISH requests to suspend CC requests from 
the caller’s agent as described in Section 6.5. The PUBLISH requests 
may be received via the URI it manages, any URI that it inserts into 
a Call-Info header, any contact URI it uses as a notifier for 
"call-completion" events, or any URI it returns as the "URI" line of 
the call-completion event packages. 


The receipt of the PUBLISH request initiates a presence event state 
for the caller’s identity at the presence server of the callee’s 
monitor as specified in [RFC3903], together with a logical presence 
server if this has not been done before for another call. 


Note: The presence server may initiate a presence event state for the 
caller’s identity on receipt of a SUBSCRIBE request as well, 
dependent on the implementation. 


The monitor SHOULD identify the addressed CCE by the request-URI of 
the PUBLISH request, or if that is not possible, by the From URI. 


Worley, et al. Standards Track [Page 19] 


RFC 6910 Completion of Calls April 2013 


If the processing of a CC request results in suspending that CC 
request by receiving a PUBLISH request from the caller’s agent as 
described in Section 6.5, the callee’s monitor MUST stop the recall 
timer and MUST ensure that the request is set to a "queued" state, 
and then the callee’s monitor MUST attempt to process another CC 
request in the queue according to its local policy. 


7.6. Receiving a CC Resumption 


When a CC request has been resumed after the callee’s monitor has 
received a PUBLISH request from the caller’s agent as described in 
Section 6.6, the presence event state for the caller’s identity at 
the presence server of the CC monitor MUST be modified as described 
in [RFC3903]. If the callee is not busy and there is no entry in the 
CC queue that is currently being processed, the callee’s monitor MUST 
process the queue as described in Section 7.3 above. 


8. Examples 
A basic call flow, with only the most significant messages of a CC 


activation and invocation shown, is as follows (please note that this 
is an example, and there may be variations in the failure responses) : 
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Caller Callee 
sip:123@a.com sip:456@b.com 
INVITE sip:456@b.com | [original call] 
| From: sip:123@a.com | 
ns 
| 487 | 
Call-Info:<sip:456@z.b.com>;purpose=call-completion;m=NR 
<------------------------- | 
SUBSCRIBE sip:456@z.b.com;m=NR [initial SUBSCRIBE] 


From: sip:123@a.com | 
Contact: sip:123@y.a.com | 
Request-Disposition: parallel 
Call-Id: abcd-efgh | 
Event: call-completion 


—------------------------ > | 

200 | 
Em | 

NOTIFY sip:123@y.a.com | [initial NOTIFY] 
Body: cc-state: queued | 
<------------------------- | 

SUBSCRIBE sip:456@b.com;m=NR [another init. SUB. ] 


From: sip:foo@example.com| 
Request-Disposition: parallel 
Call-Id: abcd-efgh | 
Event: call-completion | 


482 | [duplicate SUB. rej.] 


Body: cc-state: ready 


| | 
| NOTIFY sip:123@y.a.com | [CC invoked] 
| | 
| URI: sip:recall@z.b.com 


< A AA A Fe m A 
| INVITE sip:recall@z.b.com;m=NR [CC call] 
| From: sip:foo@example.com| 
en i 
NOTIFY sip:123@y.a.com [CC terminated] 
Expires = 0 
eo a | 
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The original call is an ordinary INVITE. It fails due to no-response 
(ring-no-answer). In this case, the callee’s governing proxy 
generates a 487 response because the proxy canceled the INVITE to the 
UA when it rang too long without an answer. The 487 response carries 
a Call-Info header field with "purpose=call-completion". The 
Call-Info header field positively indicates that CC is available for 
this failed fork of the call. The "m=NR" parameter indicates that it 
failed due to no-response, which is useful for PSTN interworking and 
assessing presence information in the callee’s monitor. 


The URI in the Call-Info header field (<sip:456@z.b.com>) is where 
the caller’s agent should subscribe for CC processing. Ideally, it 
is a globally routable URI for the callee’s monitor. In practice, it 
may be the callee’s AOR, and the SUBSCRIBE will be routed to the 
callee’s monitor only because it specifies "Event: call-completion". 


CC is activated by sending a SUBSCRIBE to all known callee’s monitor 
URIs. These can be provided by the Call-Info header field in the 
response to the INVITE. 


Additionally, the caller’s agent needs to include the original 
request-URI in its set of callee’s monitor URIs, because the call may 
have forked to additional callees whose responses the caller has not 
seen. (A SUBSCRIBE to the request-URI alone is used in cases where 
the caller’s agent has not received or cannot remember any callee’s 
monitor URI.) 


The caller’s agent adds to these URIs an 'm” parameter (if possible). 
In this case, the caller’s agent forks the SUBSCRIBE to two 
destinations as defined by Section 8.2.2.2 of [RFC3261], with 
appropriate Request-Disposition. The first SUBSCRIBE is to the URI 
from Call-Info. 


The second SUBSCRIBE is to the original request-URI and reaches the 
same callee’s monitor. Because it has the same Call-Id as the 
SUBSCRIBE that has already reached the callee’s monitor, the callee’s 
monitor rejects it with a 482, thus avoiding redundant subscriptions. 


The initial NOTIFY for the successful SUBSCRIBE has "cc-state: 
queued" in its body. Eventually, this caller is selected for CC and 
is informed of this via a NOTIFY containing "cc-state: ready". This 
NOTIFY carries a URI to which the INVITE for the CC call should be 
sent. In practice, this may be the AOR of the callee. 


The caller generates a new INVITE to the URI specified in the NOTIFY, 
or if there was no such URI or if the caller’s agent cannot remember 
it, it may use the original request-URI. The caller adds the ’m’ 
parameters (if possible), to specify CC processing. 
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PUBLISH sip:456@z.b.com 
From: sip:123@a.com 
Contact: sip:123@y.a.com 
Event: presence 
Content-Type: ’app/pidf’ 
Body: status=closed 


PUBLISH sip:456@z.b.com 
From: sip:123@a.com 
Contact: sip:123@y.a.com 
Event: presence 
Content-Type: ’app/pidf’ 
Body: status=open 


Callee 
sip:456@b.com 
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available for CC recall] 


[non-availability for recall 
is published] 


[caller becomes available 
again] 


[availability for recall 
is published] 
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For updating its presence event state at the callee’s presence 
server, the caller sends a PUBLISH request informing the presence 
server that the PIDF state is "closed". The PUBLISH request is sent 
(in order of preference) as follows: (1) out-of-dialog to the CC URI 
as received in the NOTIFY, (2) within the corresponding SUBSCRIBE 
dialog, (3) out-of-dialog to the corresponding callee’s monitor URI 
received in the Call-Info header field of the NOTIFY, or (4) out-of- 
dialog to the remote Contact address of the corresponding SUBSCRIBE 
dialog. 


When the caller is again available for the CC recall, the caller 
updates his presence event state at the callee’s presence server by 
generating a PUBLISH request informing the server that the PIDF state 
is "open"; this request will otherwise be constructed in the same way 
as the suspend PUBLISH request. 


9. ‘call-completion’ Event Package 


This section specifies the call-completion event package, in 
accordance with Section 5.4 of [RFC6665]. The call-completion event 
package has the media type "application/call-completion". 


Note that if the callee has a caller-queuing facility, the callee’s 
monitor may want to treat the CC queue as part of the queuing 
facility and include in the event package information regarding the 
state of the queue. How this information is conveyed is left for 
further standardization. 


9.1. Event Package Name 
The SIP events specification [RFC6665] requires package definitions 
to specify the name of their package or template-package. The name 
of this package is "call-completion". This value appears in the 
Event and Allow-Events header fields. 


9.2. Event Package Parameters 


No package-specific Event header field parameters are defined for 
this event package. 
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9.3. SUBSCRIBE Bodies 


[RFC6665] requires package definitions to define the usage, if any, 
of bodies in SUBSCRIBE requests. 


The SUBSCRIBE request MAY contain an Accept header field. If no 
such header field is present, it has a default value of 
"application/call-completion". If the header field is present, it 
MUST include "application/call-completion". 


A SUBSCRIBE request for a CC package MAY contain a body. This body 
defines a filter to be applied to the subscription. Filter documents 
are not specified in this document and may be the subject of future 
standardization activity. 


A SUBSCRIBE request requests CC information regarding calls recently 
made from the same caller to the callee UA(s) serviced by the 
notifier. Calls are defined to be "from the same caller" if the 
URI-part of the From header field value in the INVITE is the same as 
the URI-part of the From header field value in the SUBSCRIBE. 


9.4. Subscribe Duration 


[RFC6665] requires package definitions to define a default value for 
subscription durations and to discuss reasonable choices for 
durations when they are explicitly specified. 


If a SUBSCRIBE does not explicitly request a duration, the default 
requested duration is 3600 seconds, as that is the highest service 
duration timer value recommended for the CC services in the ETSI 
[ETS300.356-18] and ITU-T [ITU-T.Q.733] documents. Because the 
subscription duration means that no explicit timer is needed, and the 
subscription duration can be seen as an equivalent to the SS7 service 
duration timer, this specification refers to the subscription 
duration also as the service duration timer. It is RECOMMENDED that 
subscribers request, and that notifiers grant, a subscription time of 
at least 3600 seconds. 


If a notifier can determine that, according to its policy, after a 
certain duration the requested subscription can no longer proceed to 
the "ready" state, it SHOULD reduce the granted subscription time to 
that duration. If a notifier can determine that, according to its 
policy, the requested subscription can never proceed to the "ready" 
state, it should refuse the subscription. 
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9.5. NOTIFY Bodies 


[RFC6665] requires package definitions to describe the allowed set of 
body types in NOTIFY requests and to specify the default value to be 

used when there is no Accept header field in the SUBSCRIBE request. 

A NOTIFY for a call-completion event package MUST contain a body that 
describes the CC states. 


As described in [RFC6665], the NOTIFY message will contain bodies 
that describe the state of the subscribed resource. This body is in 
a format listed in the Accept header field of the SUBSCRIBE, or ina 
package-specific default format if the Accept header field was 
omitted from the SUBSCRIBE. 


In this event package, the body of the notification contains a CC 
document. All subscribers and notifiers MUST support the 
"application/call-completion" data format described in Section 10. 
The SUBSCRIBE request MAY contain an Accept header field. If no 
such header field is present, it has a default value of 
"application/call-completion". If the header field is present, it 
MUST include "application/call-completion". Of course, the 
notifications generated by the server MUST be in one of the formats 
specified in the Accept header field in the SUBSCRIBE request. 


9.6. Subscriber Generation of SUBSCRIBE Requests 


Subscribers MUST generate SUBSCRIBE requests when they want to 
subscribe to the call-completion event package at the terminating 
side in order to receive CC notifications. The generation of 
SUBSCRIBE requests can imply the usage of a CC service-specific timer 
as described in Section 9.4. 


9.7. Notifier Processing of SUBSCRIBE Requests 


Upon receiving a subscription refresh, the notifier MUST set the 
"expires" parameter of the Subscription-State header field to a value 
not higher than the current remaining duration of the subscription, 
regardless of the value received in the Expires header field (if 
present) of the subscription refresh. 


If a subscription is not successful because the CC queue has reached 
the maximum allowed number of entries (short-term denial), the 
notifier MUST send a 480 Temporarily Unavailable response to the 
subscriber, possibly with a retry-after parameter in accordance with 
the notifier’s policy. If a subscription is not successful because a 
condition has occurred that prevents and will continue to prevent the 
CC service (long-term denial), the notifier MUST send a 403 Forbidden 
response to the subscriber. 
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A notifier MAY receive multiple forks of the same SUBSCRIBE, as 
defined by Section 8.2.2.2 of [RFC3261]. In such a case, the 
notifier MUST reject all but one of the SUBSCRIBES with a 482 Merged 
Request response, unless some other failure response applies. 


The CC information can be sensitive. Therefore, all subscriptions 
SHOULD be handled with consideration of the security considerations 
discussed in Section 11, in particular for verifying the identity of 
the subscriber. 


9.8. Notifier Generation of NOTIFY Requests 


Notifiers MUST generate NOTIFY requests when the CC request’s state 
changes to "queued" or to "ready (for CC)". A NOTIFY that is sent 
with non-zero expiration MUST contain the "cc-state" parameter. The 
parameter’s value MUST be "queued" if the CC request represented by 
the subscription is not at this time selected by the callee’s monitor 
for CC recall, and the parameter’s value MUST be "ready" if the 
request is at this time selected by the callee’s monitor for CC 
recall. 


A NOTIFY sent with a zero expiration (e.g., as a confirmation of a 
request to unsubscribe) MAY contain the "cc-state" parameter. 


when the callee’s monitor withdraws the selection of the request for 
the CC recall (e.g., because the caller’s agent has not initiated the 
CC recall INVITE before the CC recall timer expires, or because the 
agent has suspended the request from being considered for CC recall), 
the notifier MUST send a NOTIFY to the subscription of the selected 
request. This NOTIFY MUST contain the "cc-state" parameter set to 
"queued". 


If the CC subscription was successful and the retain option is 
supported at the callee, the NOTIFY MUST contain the 
"cc-service-retention" parameter. 


9.9. Subscriber Processing of NOTIFY Requests 


When receiving a NOTIFY request with the cc-state set to "ready", 
subscribers SHOULD suspend all other CC subscriptions for the 
original call at other notifiers. The receipt of a NOTIFY request 
with the cc-state set to "ready" by the subscriber will also cause an 
interaction with the instances at the subscriber’s side that are 
responsible for starting the CC recall. 
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9. 


10. 


10. Handling of Forked Requests 


Forked requests are expected to be common for the CC event type. The 
subscriber MUST be prepared to process NOTIFY requests from multiple 
notifiers and to coordinate its processing of the information 
obtained from them in accordance with the procedures in this 
document. 


11. Rate of Notifications 


The CC service typically involves a single notification, per notifier 
and per subscription, regarding the change to "ready" (for CC) but 
MAY involve several notifications about the change to the "ready" 
state, separated by a CC call that failed due to a busy callee. 
Typically, notifications will be separated by at least tens of 
seconds. Notifiers SHOULD NOT generate more than three notifications 
for one subscription in any ten-second interval. Since it is 
important to avoid useless recalls, a notifier SHOULD send state 
changes to "queued" from "ready" promptly. Thus, a notifier SHOULD 
NOT send a state change to "ready" as the third notification ina 
ten-second interval, as that would make it impossible to promptly 
send a further state change to "queued". 


12. State Agents 


State agents have no defined role in the handling of the 
call-completion event package. 


CC Information Format 


The following syntax specification uses the Augmented Backus-Naur 
Form (ABNF) as described in [RFC5234]. The formal syntax for the 
application/call-completion MIME type is described below. In 
general, the CC body is to be interpreted in the same way as SIP 
headers: (1) the names of the lines are case-insensitive, (2) the 
lines can be continued over line boundaries if the succeeding lines 
start with horizontal white space, and (3) lines with unknown names 
are to be ignored. The header lines defined in this document can 
occur at most once in any given CC information format document. 


call-completion = 1* (cc-header CRLF) 


cc-header = cc-state / cc-service-retention / cc-URI / 
extension-header 


The above rules whose names start with "cc-" are described below. 
Other rules are described in [RFC3261]. 


Worley, et al. Standards Track [Page 28] 


RFC 6910 Completion of Calls April 2013 


10. 


10 


10. 


11. 


1. CC Status 


The cc-state line indicates the CC status of a particular user with 
an entry in a CC queue. It MUST be present, unless the expiration 
time indicated in the NOTIFY is zero. 


ec-state = "cc-state" HCOLON ( "queued" / "ready" ) 
The value "queued" indicates that a subscriber's entry in the CC 


queue is not selected for CC recall. The value "ready" indicates 
that a user's entry in the CC queue has been selected for CC recall. 


.2. CC Service-Retention Indication 


The service-retention line indicates the support of the retain 
option. The retain option, if supported at the callee, will maintain 
the entry in the CC queue, if a CC call has failed due to a Callee 
busy condition. If present, this parameter indicates that the retain 
option is supported; otherwise, it is not supported. This parameter 
MAY be present in NOTIFY requests. 


cc-service-retention = "cc-service-retention" HCOLON "true" 
3. CC URI 


The cc-URI line provides a URI that the agent SHOULD use as the 
request-URI of the CC recall INVITE and the suspend/resume PUBLISH. 
It SHOULD be provided in all NOTIFYs. The URI SHOULD be globally 
routable and SHOULD uniquely identify the CCE in question. The 
syntax provides for generic-params in the value, but this document 
defines no such parameters. Parameters that are not understood by 
the subscriber MUST be retained with the URI. 


cc-URI = "cc-URI" HCOLON addr-spec 
Security Considerations 


The CC facility allows the caller’s agent to determine some status 
information regarding the callee. This information intrinsically 
diminishes the privacy of the callee; in order to protect 
sufficiently the privacy of the callee, the overall amount of 
disclosure must be limited, and the amount of disclosure to any 
single caller must be limited. 


Of course, if a caller is not permitted to call the callee, that 
caller should not be allowed to establish a CC subscription. Callers 
that are particularly sensitive about their privacy may reject all CC 
subscriptions. But in the ordinary case, the optimal protection is 
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to permit any caller to subscribe but prevent any caller from 
subscribing for too long, or too often, or in a pattern that does not 
reveal to the callee (through CC calls) that the subscriptions are 
taking place. 


In legitimate use, CC event subscriptions will be made in stereotyped 
ways that limit the disclosure of status information: 


1. When a subscriber is selected for CC, a call should arrive 
promptly for the callee, or the subscription should be 
terminated. This expectation may be violated by a race condition 
between selection of the subscription for CC and the caller 
becoming unavailable, but it should be rare that a single 
subscription will exhibit the race condition more than once. 


2. Subscriptions should not remain suspended for longer than the 
expected duration of a call (a call by the caller to a third 
party). 


3. Subscriptions should be initiated only shortly after failed 
incoming calls. 


4. Most of the time, a callee should have no queued subscriptions. 


Violations of these expectations should be detected by the callee’s 
monitor and reported as possible attempts at privacy violation. 


The CC facility may enhance the effectiveness of Spam over Internet 
Telephony (SPIT) via the following technique: the caller makes calls 
to a group of callees. The caller then requests CC for the calls 
that do not connect to the callees. The resultant CC calls are 
probably more likely to reach the callees than original calls to a 
further group of targets. 


In order to prevent senders of SUBSCRIBE and PUBLISH requests from 
causing Denial-of-Service (DoS) attacks and suspending other CC 
entries than their own, a mechanism to correlate the identity of the 
original caller and the sender of SUBSCRIBE and PUBLISH requests is 
needed. The RECOMMENDED mechanism to authenticate the identity of 
the originator of requests relevant to CC is the SIP Identity 
mechanism [RFC4474]. Alternatively, CC agents and monitors within an 
administrative domain or federation of domains MAY use the mechanism 
described in [RFC3325] to authenticate their identities with a 
P-Asserted-Identity header field. 


Furthermore, the use of the presence server to suspend or resume 
SHOULD be limited to a caller that has an active queue in the 
callee’s monitor. This can be achieved first by monitoring and 
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logging incoming calls to the callee and the destination where CC 
indication was sent, then to ensure that subscription to the 
call-completion event package is permitted only within a short time 
frame after the initial call failed and to only accept PUBLISH 
requests to the presence server if there is an active queue for the 
caller in question. 


Note that regarding authentication/authorization/billing logic 
subject to operator policy, CC calls or subscriptions do not differ 
from other basic calls or event subscriptions. 

12. IANA Considerations 

12.1. SIP Event Package Registration for CC 
This specification registers an event package, based on the 
registration procedures defined in [RFC6665]. The following 
information is required for such a registration: 
Package name: call-completion 
Is this registration for a Template-Package: No. 


Published specification: RFC 6910. 


Person & email address to contact for further information: Martin 
Huelsemann, martin.huelsemann@telekom.de 


12.2. MIME Registration for application/call-completion 
MIME media type name: application 
MIME subtype name: call-completion 
Required parameters: none. 
Optional parameters: none. 


Encoding considerations: Consists of lines of UTF-8-encoded 
characters, ended with CRLF. 


Security considerations: There are no security considerations 
internal to the media type. Its typical usage involves the security 
considerations described in RFC 6910. 


Interoperability considerations: See RFC 6910. 


Published specification: RFC 6910. 
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Applications that use this media type: The implementations of the CC 
features of the Session Initiation Protocol. 

Additional information: 
Magic number(s): none 
File extension(s): Not expected to be stored in files. 
Macintosh file type code(s): Not expected to be stored in files. 


Person & email address to contact for further information: 
Martin Huelsemann, martin.huelsemann@telekom.de 


Intended usage: LIMITED USE 
Restrictions on usage: none 
Author/Change controller: The IETF 


2.13". SIP/SIPS URI Parameter 'm' 


This specification defines one new SIP/SIPS URI parameter ’m’ as per 
the registry created by [RFC3969]. It is used to identify that an 
INVITE request is a CC call, or to further identify that a SUBSCRIBE 
request is for the call-completion event package. The parameter may 
have a value that describes the type of the CC operation, as 
described in this specification. 


Name of the parameter: m 
Predefined values: yes 


Reference: [RFC6910] 
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13. 


4. The 'purpose” Parameter Value ’call-completion’ 
This specification adds a new predefined value "call-completion" for 
the ’purpose’ header field parameter of the Call-Info header field. 
This modifies the registry header field parameters and parameter 
values by adding this RFC as a reference to the line for header field 
"Call-Info" and parameter name ’purpose’: 
Header field: Call-Info 
Parameter name: purpose 
Predefined values: yes 
Reference: [RFC3261] [RFC5367] [RFC6910] 
5. ‘’m’ Header Parameter for Call-Info 
This specification extends [RFC3261] to add a new header field 
parameter 'm” to the Call-Info header field. This adds a row to the 
registry header field parameters and parameter values: 
Header field: Call-Info 
Parameter name: m 
Predefined values: yes 
Reference: [RFC6910] 
The predefined values are ’BS’, 'NR', and ‘NL’. 
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Appendix A. Example Caller’s Agent 


This section outlines how an autonomous caller’s agent can operate 

using only standard SIP features to interact with the caller’s UA. 

This example is suitable only as a learning aid, as its performance 
is poor. 


The agent monitors calls made from the UA(s) by subscribing to the 
dialog event package of the UA(s). 


The UA(s) or their proxy routes calls made with either of two special 
dial sequences to the agent, which interprets the INVITEs as 
indications to make a CC request with BS or NR or NL mode for the 
latest call made by the UA. 


The agent monitors the status of the UA(s) for availability to be 
used for a CC call by examining the dialog events. 


The agent indicates to the UA(s) that CC recall is in progress by 
making call to the UA(s). If the UA is answered, the agent assumes 
that the caller is available and plays pre-recorded audio to indicate 
that CC recall is in progress. 


After playing the pre-recorded audio, the caller’s agent uses REFER 
to order the UA to make the CC call to the callee. 


Appendix B. Example Callee’s Monitor 


This section outlines how an autonomous callee’s monitor can operate 
using only standard SIP features to interact with the callee’s UA. 
This example is suitable only as a learning aid, as its performance 
is poor. 


The callee’s monitor monitors calls made to the UA(s) by subscribing 
to the dialog events of the UA(s). This enables it to determine 
their Call-Ids and their final response statuses. 


The proxy for the UA(s) routes to the callee’s monitor any SUBSCRIBES 
for the call-completion event package directed to the URIs serviced 
by the UA(s). 


The callee’s monitor monitors the status of the UA(s) to determine 
when they are in a suitable state to receive a CC call by watching 
the busy/not-busy status of the UA(s): for example, a UA is available 
for CCBS when it is not busy, but a UA is available for CCNR when it 
becomes not busy after being busy with an established call. 
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